NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/13408

Internet Message Format | 1996-08-05 | 4.3 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: Variant Records in C ... Is there a way ?
Date: Sat, 06 Apr 96 18:24:41 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <4iumf8$[e-mail]> <danpop.827534657@rscernix> <4jcrbm$[e-mail]> <[e-mail]> <4jvdhj$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4jvdhj$[e-mail]>
           [e-mail] "Michael A. Balfour" writes:

>In a previous article, [e-mail] (Lawrence Kirby) says:
>
>>In article <4jcrbm$[e-mail]>
>>           [e-mail] "Michael A. Balfour" writes:
>>
>>>
>>>In a previous article, [e-mail] (Dan Pop) says:
>>>
>>>>In <4iumf8$[e-mail]> [e-mail] (Michael A. Balfour)
>>> writes:
>>>>
>>>>>*However*, if you feel like it, you can still do it yourself with some
>>>>>clever mallocs and overlaying structures.  Not exactly elegant, but you
>>>>>can make it pretty memory-efficient.
>>>>
>>>>Not exactly blessed by the C standard, either :-)
>>>>
>>>
>>>Maybe not blessed, but it's certainly not condemned.
>>
>>You'll almost certainly invoke undefined behaviour as far as the language
>>is concerned. So it is in the same category as void main() or i = i++,
>>i.e. condemned to be non-portable.
>>
>
>You're willing to make a broad generalization, but you aren't backing it
>up with any substance.  *Why* will it almost certainly invoke undefined
>behavior?  You're allowed to treat memory like a series of bytes or
>chars, and that's *extremely* well-defined.

It is defined in as much as you are guaranteed not to have aliasing problems.
What the results are are not at all clearly defined.

The statement was about overlaying structures. That will almost certainly
invoke undefined behaviour e.g. if I access an object of type struct a
through an lvalue of type struct b then that results in undefined behaviour,
even if the member lists of struct a and struct b are identical (the only
instance where this is well defined is if a variable with external linkage
is defined as struct a in one translation unit and struct b in another).
In terms ofaccessing the structure members the following is significant from
the standard 6.3.2.3:

"If a union contains several structures that share a common initial sequence
 (see below), and if the union object currently contains one of these
 structures, it is permitted to inspect the common initial part of any of
 them. Two strcutures share a commom initial sequence if corresponding members
 have compatible types (and, for bit-fields, the same widths) for a sequence
 of one or more initial members".

So there are circumstances where it is legal but not when you are accessing
a member through another with incompatible type.

> Of course, treating it
>correctly is always up to the programmer, but there's no reason why a
>programmer will "almost certainly" do it wrong.

I'm not saying that the code won't work on a particular implementation (or
even most implementations), simply that it very likely to result in undefined
behaviour as far as the C language is concerned.

>In fact, it sounds like you agree with me a little later in your post:
>
>>The language does give license to access any object through character
>>lvalues. It has been suggested that future revisions of the standard will
>>clarify the issue so that, say copying an object as an array of unsigned char
>>works (as long as you end up with suitable alignment). Anyway this is a better
>>approach than using unions.
>
>See?

I see that that approach avoids the issues of using structures and unions.

>>That doesn't mean that ANSI C will guarantee that your code does what
>>you expect.
>>
>
>Of course not.  In fact, relying on variables names to understand code
>doesn't always give you what you expect either.

The expectations were fairly clear in this case.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------